TPUG - Toronto PET Users Group

home *** CD-ROM | disk | FTP | other *** search

/ TPUG - Toronto PET Users Group / TPUG Users Group CD / TPUG Users Group CD.iso / AMIGA / (A)TB / (A)TBK.ADF / AIBB / AIBB2.doc < prev next >

Wrap

Text File | 1991-02-10 | 49KB | 786 lines

Amiga Intuition Based Benchmarks Version 2.0 ⌐1990 LaMonte Koop This program is designed to test various aspects of CPU performance on your Amiga. I must note that the tests used are for evaluating CPU perfomance ONLY, and not math coprocessor performance. FPU support is not included in this version, but may be in a future release. The comparisons made within the program are designed to be a 'General' type of comparison. They are far from 'exact to 0.000000000xx percentage or somesuch. Because of the nature of computer systems, and the fact that differences can occur between two machines of the same type, the comparisons I make should be used as an average view of the systems compared. Many comparison samples were used to gather these figures, and most come within a good proximity of the values. The conditions under which these values were obtained is explained in the documentation below. If you want to REALLY be sure of the comparisons, ideally you should run the tests on your machine, record the time value each test displays (the time the test took to run), and do the same thing to the machine you wish to compare to, and evaluate the results. This program will give you an average result answer however, allowing you to make general comparisons with other types of accelerators and machines. Please do read the subsection under menus describing the 'Be Selfish' option...there are some warnings you MUST read there. As with all benchmarks, a certain environment had to be set up for the base results used for the comparisons. Please do read the sections pertaining to the environment used for the base machines in AIBB's comparisons. Legal Information: (gasp...choke...) Amiga, all Amiga models, and Intuition are trademarks of Commodore-Amiga Inc. MC68000, MC68010, MC68020, MC68030, and MC68040 microprocessor designations trademarks of Motorola Inc. Disclaimer: I make no guarantees that this program will be accurate. I have made every attempt to make it so, but I cannot be held responsible for its accuracy, and/or consequences of such. (In other words, include standard disclaimer here :-) ) Also, should this program maim and/or destroy various aspects of your Amiga, I am also not responsible. (Well...it hasn't killed yet...): Another meaning; if you run this program, and something about it surprises you, causing you to spill coffee into your machine, which sends a power spike feedback through the power lines, down to your local power station, which subsequently explodes in flames..., I don't, and never did exist. ;^) This program has been a GREAT deal of work...I consider it to be of a 'Share/Free' ware type of release. I make no REQUIREMENT that a donation or fee be sent, but if you find it very useful, anything would be appreciated (cars...spare Amiga 3000s...large sums of cash :-) ). In any case, AIBB is NOT PUBLIC DOMAIN! You may not change it or modify it...and certainly don't call it your own program... That'd really bug me <^_^>. ----------------------------------------------------------------------------- PROGRAM REQUIREMENTS: This program can be used on any Amiga...but there are a few requirements to use all of it's features. First, to use all of the test features, it should be started with a stack setting of 12000. The icon included will do this for you, or you can do it yourself from the CLI. Second, in order to use the Log File saving utility, you must have either the arp.library, or req.library in you libs: directory. Please read the appropriate sections below for more information on these topics. Note that these requirements are not in actuality 'requirements' for the entire use of the program, but rather for certain features of it. USING THE PROGRAM: This program was designed to be fairly easy to use...which is the reason I utilized an Intuition interface. Basically, test options and such are selected from menu items, and a test is intiated by selecting it's gadget on the screen. Again, note that the comparisons made in this program are meant to be general. Here's an overview: Menu Items: The menu fields in the menu bar for AIBB are as explained below: The 'General' menu: About: This simply shows my neato little 'about the program and life in general' requester. Fairly standard stuff. System Status: A few key points of interest about your system will be displayed. Among them are: Exec library version: (aww...why not? :-) ); System Stack location: The system stack on the Amiga is normally located in either CHIP (for 1+ meg CHIP RAM machines), or SLOW- FAST RAM (for 512K CHIP RAM machines). There are programs available which will move the system stack into FAST RAM. This allows the system to access said stack area without possible contention occuring on the CHIP RAM bus, and can somewhat improve system performance. [Not a GREAT deal, but anything counts :-) ]. Memory Information: Your currently available CHIP and FAST ram is displayed, along with figures denoting the largest available contiguous chunk of said memory types. These 'chunk' figures are important, as AIBB allocates memory for certain tests, and if a large enough contiguous memory area is not available in FAST RAM, the system will search the memory lists until it finds one (or fails), and just may allocate the memory in a slower medium. Start/Stop Log File: This will allow you to activate/deactivate AIBB's saving of test results. [The menu will show 'Start' when you are currently NOT saving results, and 'Stop' when you are]. When first selected, AIBB will call up a file requester asking you for the name of the Log file to use. Currently, 2 file requesters are supported...the one found in Colin Fox & Bruce Dawson's requester library (req.library), and the standard ARP requester library...you will need either the req.library or arp.library in your libs: directory to have access to this saving feature [Worry not...I'm writing my own requester as well, and will probably make an update AIBB with it, if you do not want these shared libraries]. AIBB prefers the req.library requester, and will first look for it...it then will attempt to gain access to the arp.library...If it cannot find either of these, it will disable this menu function. When a file is selected, AIBB first checks to see if it exists. If not, it will create it, writing the identifier 'AIBBLogFile' at the head of the file (standard text file). All future test results will be appended to this file, until 'Stop Log File' is selected, or the program exits. [Note: it is NOT necessary to stop file logging before exiting...it is mainly there if you wish to make another file]. If the file you select DOES exist, AIBB will check the beginning of the file for the 'AIBBLogFile' identifier...if it finds this, it will again append all results to the end of this file (nothing will be overwritten)...if AIBB does not find the identifier at the start of the file, a requester will pop up warning that the file is NOT a standard AIBB log file, and will ask you if you wish to cancel the operation, OR use the file anyway. Be careful..this warning is designed to keep you from writing over important files...or programs. [NOTE: AIBB WILL write into a binary file if told to continue...I will add some better checking in the future, but for now, WATCH the warning!]. About the file requesters: Personally, I find the one in the 'req.library' much more appealing...try that one if you at all can. The next version of AIBB will support the AmigaOS 2.0 standard file requester as well, and will favor that one over the others it checks for. Note that AIBB does not buffer results...it writes to the file as soon as a test is completed. This shouldn't be too much of a problem, but if people find it irritating, I will of course add in some buffering. If desired, RAM: or a recoverable RAMdisk can be used to save results, but care should be taken that the space the file takes will not use up FAST RAM to an extent that the test results will be affected. Quit: Self explanatory. (I hope) The machine will be placed back into it's baby original state when the program exits...regardless of the manipulations which may have been done during the tests (See the section on 680x0 cache manipulation) The 'Test Options' field contains: Be Selfish: This is an important item. Basically, when this is selected, the program will make sure no other tasks are given CPU time while one of the tests is running. In this way, you are assured that the test results will reflect true CPU performance, and not lag due to other tasks taking up some of the CPU's time. All of the comparison figures for the other machines were obtained with this option ON (A check will be placed by the option when it is active), SO IF YOU WISH TO COMPARE TO THE OTHER MACHINES IN THE PROGRAM MOST ACCURATELY, HAVE 'Be Selfish' SELECTED!!! <whew>. Read on...When 'Be Selfish' is active, the system will not respond to you while a test is running. Meaning, you will not be able to move your mouse pointer, and that most enjoyable floppy drive 'clicking' will even stop. THIS IS NORMAL! You will regain control when the test completes...the system did not hang. Some tests do take a little time, so hang in there. The only time you will really not want to have 'Be Selfish' active is if you wish to test the performance drain on your system from having multiple tasks running. (or just to see what the normal load of tasks does to your CPU performance). Now...you must know something about this option. What I do when this option is enabled is invoke a Disable() call a bit befpre each test, and then an Enable() afterwards. Disable() effectively STOPs all interrupts within the system. Since multitasking is interrupt-driven, this is also stopped, and my task becomes the only one doing anything (there are exceptions...that is explained later). ALL this aside, I MUST give you a warning. I designed this program to test CPU performance, and as such it is a good idea to have as little running in the background as possible...aside from performance issues though, there are some programs/operations which are very timing sensitive. If you are running one of these in the background, then DO NOT use 'Be Selfish'...I suggest just waiting until you are done with that operation before using this program. This is especially true of Disk-based operations...it is possible that if you are doing a large r/w operation on your Hard Drive, or floppy, and run this program with 'Be Selfish' enabled, you could run into problems. To be safe, just consider such things a no-no. NOTE: AIBB's own file saving is done in a safe way, and CAN be used with 'Be Selfish', as the program only accesses the disk when not performing a test. Anyway, since you want to use this program to test CPU performance, it is best to run it basically alone. The program defaults to NOT using Be Selfish so that the quick-to-jump-in person will not feel my program has locked-up the system when they go to do a test. The first time you select 'Be Selfish' from the menu, a requester will pop up reminding you of what I just said here. Once the requester has appeared the first time, it will not appear again during the course of the program's execution, regardless of how you set the Be Selfish menu option (otherwise it could become quite annoying :-) ) Now, with 'Be Selfish' NOT enabled, there are no restrictions to this program's use, but again you will show a marked performance drop. Comp. Machine Type: This menu item allows you to change the type of machines you will be comparing yours to. When selected, a submenu will appear next to it with the items MC68030 and OTHERS within it. Simply, selecting MC68030 sets the program for comparing 68030 based machines and the OTHERS item sets the program for comparing a few other selected machines, the A2500/20 equipped with a 14.28MHz 68020, and a 68010 equipped A2000 running at the normal 7.14MHz clock. The default selection is for 68030 machines. Note that no matter which machine type is selected, the one constant here is the standard A2000. The A2000 will always be one of the comparison machines regardless of the type selected. Do read the section below labeled 'Alt A2000 base' however. The current comparison machines for each type are: (and the setting used to get the internal figures) 68030: A2500/30--or equivalently an A2000 fitted with an A2630 accelerator. This machine uses a 25MHz processor. The internal comparison figures for this machine were obtained for the following setups: 4 megs of 100ns 32-bit RAM were used, and the ROM image was mapped into the 32-bit RAM area using Dave Haynie's SetCPU v1.6 program. The exact SetCPU setting was: SETCPU: 68030 FASTROM (INST: CACHE BURST) (DATA: CACHE BURST). Although on a 2500/30 the BURST setting has no effect on the current setup. (Can't hurt to leave it set though :-) ). In addition, each test WAS performed with a minimal of background tasks running...regardless of the 'Be Selfish' option, which was used at all times. ---------------------------------------------- A3000/25--An Amiga 3000 using a 25MHz 68030 was used for the comparison machine in this program. The A3000s used for the comparisons were NOT equipped with Static-Column type FAST RAM, but rather with standard DRAMs. I did make an analysis of SCRAM over DRAM speed, and while there is a difference, I felt it best to include a more or less 'stock' type of A3000 here. Since the ROMs are already on a 32-bit bus for this machine, no action was (or needed to be) taken in respect to that. For cache settings, both the instruction and data caches were ON. BURST mode again was not in effect due to the system configuration. OTHERS: 68010 Amiga: This is basically just a standard Amiga 2000 fitted with a 68010 processor in place of the 68000. As with the 68000 Amiga 2000, all tests were conducted in a FAST RAM environment. A2500/20: This is the original version of the 2500...an Amiga fitted with a 14.28MHz 68020, and 2 megabytes of 100ns 32-bit RAM. Again, SetCPU 1.6 was used to move the system ROM image into the 32-bit environment. None of the comparison machines was running any special performance enhancing program, such as MoveSSP or VBR, which improve performance by moving certain data from CHIP to FAST RAM to avoid the bus contention in CHIP RAM. Note that these programs are irrelevant for the machines using SetCPU v1.6 to move the ROM image into 32-bit RAM. SetCPU v1.6 will perform these functions itself, and thus this does play a factor for those machines. They were not used for the A2000 and 68010 based A2000. If you use any of these programs, on an A2000, you may notice a slight increase in performance over the similar machine in the comparison lineup. This increase may be small enough, however that it will not show up definitively on the graph or percentages, as account of the error margin. I must make mention of the fact that for all machines used for the internal comparisons, v1.3 of AmigaOS was used. This INCLUDES the A3000 measurements. The reason I did not use 2.0 is that there IS a difference in machine performance when using v2.0 of AmigaOS. When 2.0 becomes widely available, I intend to update the program to handle measurements for that version of the OS. If you are using 2.0, this program will work fine, but you cannot use the comparisons to any real accuracy, because as of this writing, 2.0 was not burned into ROM, and the version being used was of a RAM-based KickStart variety. This has the effect of giving either falsly high, or occasionally low, readings for time results and thus affects the comparisons. [An actual ROM image will vary from a RAM based image, due to the differences in the medium]. AIBB will be updated, of course, and if 2.0 does come into ROM soon, you could use this version to test the new OS's speed for some of the comparisons which are dependent on OS functions against 1.3 figures. Also bear in mind that the A3000 is a very new machine, and has in fact had several components updated over it's life so far... (including the 'Buster' RAM controller). In fact, you should consider the A3000 results contained in this program to be 'preliminary'...if I find that something has changed the performance of future A3000s, I shall update AIBB accordingly..[Also, some earlier A3000s may show slight variations due to the above reasons]. NOTE: All machines used internally are NTSC-based machines. PAL machines may show false performance readings for the comparisons. In addition, overscanned displays *MAY* have an effect on test results if they are active at the same time the program is running. Also, the A3000 productivity mode is notorious for sucking up the system bandwidth, so keep this in mind. Change Base: This menu item allows the selection of the machine to be used as the base in the percentage comparisons. The submenu which appears next to it allows you to choose which machine you wish to use as the base machine...the default being the A2000. With any base, the percentages, and the graph show the performance of both your machine, and the other machines as compared to the base. The base machine will always show itself to have a relative performance of 100% (naturally, as it's evaluating itself against itself). The other machines will show percentages relative to the base machine's performance. Large Graph Scale: This is an option I added when it became apparent that some of new 68040 boards to be (or have been..depending on when you read this) released were just to fast to fit on the normal graph scale for any test. When this item has been selected (checked), the graph scale will double in size...this will be apparent on the screen, as the scale will no longer go from 0 to 14 (0-1400%), but rather from 0 to 28 (0-2800%). Probably the only time you would wish to do this is if your machine goes off the scale during any test while using the standard scale. Alt. A2000 Base: This menu function serves a purpose which will only be necessary for certain individuals. When evaluating the performance of the A2000, I came across some interesting results...Some machines ran the test SLOWER than others. Generally, the same machines showed the slower results on a consistant basis...so this menu function. When you select this menu function, AIBB will use a different set of internal comparisons for the A2000...these will reflect the slower performance of these certain machines. If you are running an A2000, and are within all the other parameters used for the tests, and results are still coming up slow, select this menu function. Now, if you are using an accelerator, and are comparing to other machines, this setting makes NO difference. The slower figures turn out to be a certain factor slower than the 'normal' figures, so the net result will be that selecting either of these will simply end up in a 'shifting' of the other results...including your own by the same amount. Hence, comparisons between the other machines are not affected...it is probably a good idea to stick with the default 'faster' results though, in order to get an idea of how your system marks against an A2000 running at this speed, percentage wise...and most A2000s run at this. I've found a few that do not, and I have some ideas related to the memory they are using, and possible the Gary chip version, but the results for those specific machines were always slower, wheras 'faster' machines ALWAYS showed faster, thus I have eliminated coding errors from this phenomena. Stack Variables: This menu item is somewhat mislabled, but that's ok. What this does is such: When the item is selected, (checked), The program will use Stack-allocated variables for the Sieve and Matrix tests. Since these tests use rather large variable arrays, this is the reason I mentioned you must have a stack setting of 12000 or greater in order to use this function. The reason I included this item is that the systems do run faster with these tests when the variables used in this way. When the program is first started, it will look at what your current stack setting for it is...if it is 12000 or greater, it will invoke this menu item automatically as the default. If you use a stack setting lower, it will use the alternate method of test variable allocation, and ghost this menu selection. The alternate way of variable allocation uses memory allocation calls to reserve an area of memory for my test variables. Because of this, it is an interesting way to test the differences between memory speeds for different machines (or even your own, with a few tricks :-) ). Note that this menu item only affects the Sieve and Matrix tests. The program will adjust its comparison figures to the setup you have selected. NOTE: This is in no way connected with the System Stack mentioned earlier in the System Status menu section. The Stack being referred to here is the program stack, which is completely seperate and is allocated when the program's task is created upon startup. The speed difference you will see between the two is base upon the fact that for the external memory-allocated variables, the program must make full address memory accesses to reference the variables, whereas in the stack method, they are pulled off the program stack. The difference is not great, but it is interesting to note. Depending on the processor your machine has, you may find another menu, 'Processor'. This field only appears if you are running a 68020 or above and allows you to switch the caches of your processor on/off, to see the effects doing this has on test results. The menu configures itself to your processor type, so if you are running a 68020, the only item that will appear under this menu is 'Switch I-Cache'. For higher processors, items to manipulate the Data and Instruction cache, and the BURST modes will also appear. When a cache is changed this way, the new cache status will appear in the CPU status indication area explained below. If you do choose to manipulate the caches during the tests, and get lazy and don't set them back the way they were, the program will automatically set the caches to the state they were in upon startup when you quit the program. NOTE: As I indicated, if you are running a 68000 or 68010, this menu will not be present, as it is of no use to those processors. (Besides, if you try to set a Cache Control Register (CACR) value on a 68000 or 68010, neither of which have a CACR...you get a nice, and pleasant light/sound effects show... and associated strange happenings. :-) ) Also, although the choice for switching BURST mode on may appear for your machine's processor, it may have no effect. This is because your processor must be capable of using this mode, and some are not. If you switch it on and your machine isn't able to use it, no harm will come of it. In fact, the program will still set the BURST enable bit(s) in the Cache Control Register, but the processor will simply ignore them. [It'll look at what I did and say 'huh?' ;^) ]. The Screen: The screen is divided into two areas. On the left side, you will find the performance graph, and CPU status indications. The performance graph is basically just a graphical display of the percentage performance of the various machines, including your own. The scale, numbered from 0 to 14, represents percentages in hundreds, i.e. a factor of 6 would be 600%, etc... If for some reason your machine measures off the scale (LUCKY YOU!!!) then the graph will not be displayed above 14 (1400%), but will stop there and show a plus (+) sign above the graph bar. The CPU status area is directly below the graph, and shows the CPU type in your system, and the status of the various caches, if applicable, as well as if burst mode on the caches has been enabled. If your CPU does not have a particular cache feature, the display will show 'NONE'. The right side of the display contains the numerical analysis display boxes and the test selection gadgets. From top to bottom, the features are: Benchmark Result: This box shows the running time in seconds for the benchmark performed. It is not a comparison, but simply a display of the time used in performing the benchmark. Base Machine = : This area will show what machine is currently being used as the base machine for percentage calculations. The next 4 boxes in decending order are the numerical representations of the percentage performance of each machine for a particular benchmark. Note that even if your machine happens to go off the graph scale, the numerical percentage will still be shown here, so you will still get a performance evaluation. Remember that all percentage calculations are percentages of the base machine, where the base machine will always show 100% performance (naturally, as it is relative to itself). The bottom portion of the right side display area contains the test selection gadgets. A description of the test each performs is outlined below: WritePixel: This is a derivation of the original SetAPen/WritePixel first introduced by Computer Systems Associates (CSA). It draws a box on the screen one pixel at a time using the OS function call Writepixel(), then erases the box in the same manner. The test is useful mainly for testing the speed increase of systems which have their KickStart images mapped into a 32-bit RAM environment. Sieve: The Sieve test used here is the basic Sieve of Erathosthenes test for prime numbers. It searches a set of 8191 numbers for primes in a loop 100 iterations in length. Sort: The Sort test I use here is a simple shell-sort algorithm for sorting integers. I do not use a random list of numbers to sort, as that would result in different benchmark times depending on the way the list turned out, but rather I use my own 'mixing' method for scrambling the numbers so they are mixed in the same way every time. The test measures the time it takes to order the resultant mess (12000 numbers). Savage: This test is just a loop test of performing a series of nested floating point operations on a number. This test requires the use of the Amiga's MathTrans.library, which should be in your libs: directory. NOTE: The performance figures for the other machines were obtained using the mathtrans.library which comes with the WorkBench on the Amiga. There are versions of this library around which map those functions and such to a math coprocessor. If you wish to compare your machine on par with the machines represented internally, you should NOT be using one of these other libraries. (It would be quite an unfair advantage :-) ). If the program cannot find the mathtrans.library in your libs: directory, it will inform you of the problem and disable the Savage test gadget. Dhrystone: This one should be fairly familiar to most people. It is a standard port of the ever-popular Dhrystone benchmark used on so many systems. It is a close port of the original version written in ADA by Reinhold P. Weicker, and the Modula-2 port by Joergen Thomsen. Matrix: A simple matrix addition/multiplication benchmark on three 40x40 integer matrices. With a loop increment added to smooth out fluxuations. The time in the loop is factored out of the returned time and percentage calculations. Now, none of these tests has been 'optimized' in any way. Thus, you may notice that, for instance, you get a lower dhrystone/second rating on your machine than other programs show. This is not a problem. Since the comparisons are done from figures recieved from this program, running this code, the percentage differences between machines are valid, in that sense. (A different machine will just run the code the same percentage slower, or faster, and get a results proportional to the others). Why did I use these 'slow' unoptimized tests? Simple...if I wanted to compare compiler efficiency, then I would want to optimize the code (for instance, the dhrystone test will run faster using 32-bit long addressing, rather than 16-bit base A4 register offset addressing, and using register variables could speed things up a great deal). However, I am NOT comparing compiler/language speeds here. The goal is to find the speed of the system relative to others. Optimizing the code negates this goal...an optimizing compiler run can play all sorts of neat tricks on the benchmark...entire loops can be removed if the compiler senses they serve no purpose, etc... Doing said things is not a good way to test system performance, so I chose to leave the tests completely unoptimized. General Notes: The tests performance figures here are meant to give you a general idea of the performance of your machine. As is always with benchmarks, there is a margin of error, and certain circumstances can increase that margin. To get the minimum error from these tests, I recommend the following: (Of course any of these can be disregarded if you are trying to see the performance of your system in different environments...this is only a general guideline to duplicate the test conditions for the machines being compared against) 1.) Make SURE you are running in FAST RAM only. Due to bus contention, running in CHIP or SLOW-FAST RAM (address $C00000) can cause a reduction in performance. If the program detects it has been loaded into CHIP or SLOW-FAST RAM, it will pop a requester up informing you of this, but this does not tell you everything. This requester will only appear if the MAIN program ends up using these memory mediums. The tests themselves allocate some memory when performed, and if you happen to get AIBB squeezed into the last dregs of your FAST RAM, the tests themselves may be force to use CHIP or SLOW-FAST RAM, thus degrading performance. In general, try to be sure you have at least 50K of FAST RAM sitting free after AIBB itself loads up. And of course, if you are using an accelerator with 32-bit RAM, FAST RAM to you should mean the 32-bit variety. Also a warning for 16-bit RAM: You may have plenty of FAST RAM on your system, but there is a caveat. You must be sure that the true FAST RAM you have is highest on the system memory priority. Simply put, if you do not have the 1-megabyte Fat Agnus chip, that SLOW-FAST memory at location $C00000 will end up at the same priority as your true FAST RAM, UNLESS you have the program FastMemFirst called from your startup-sequence. Alternatively, you can set the priority manually with a program called MemPri. Just be sure your true FAST RAM has priority over all other memory. This precaution is mainly for people not running accelerators, as the memory on accelerators is usually set up as highest priority to begin with (and you WILL notice if it is not...) 2.) Although while using the 'Be Selfish' option all other tasks will not be allocated CPU time, a good general rule is to try to have as few large tasks running in the background as possible. The reason for this is that as mentioned above the tests do allocate memory for themselves when invoked, and if another task suddenly eats a large portion of memory, the test may be forced to use memory which turns out slower (CHIP, SLOW-FAST, or on 32-bit machines 16-bit memory may end up being used). Also, if you are doing some graphics/blitter work in the background, and run the tests, Be Selfish may be overridden. Some graphics functions, and most notably the blitter, can break any hold on task switching, including a Disable() or Forbid(). In particular, if a function makes a Wait() call, this can temporarily undo a Disable(), thus negating a section of the benchmark run. Moreover, the data and instruction caches on so-equipped machines are also dealing with the code and data being used by other tasks when they are running, so I have found the most consistant and accurate tests come out when having as few other tasks running as possible. Usually the internal caches don't play TOO much of a part in this, but still for the best results possible running alone is the best way to use this program for accuracy. However, you CAN still get a general idea otherwise. 3.) To get the best figures, run a test more than once. The figures will stabilize after the first test or so (as the caches on such equipped machines end up with more of the test code than before). This is especially true of the WritePixel and Dhrystone tests. The Dhrystone test may continue to fluxuate slightly even after a few tests. This is mainly due to which parts of it end up being cached, and cannot be eliminated. The caches on 030 and 020 processors are marvelous speed enhancers, but they also make accurate benchmarks a nightmare. The dhrystone test particularly is a pain to get real stable figures from. It has a tendency to have different parts of it cached during different runs, making for slightly different results over time. Now, the fluxuation is not tremendously great, and you will still be able to get a fairly good CPU performance evaluation. Note however that this is one of the reasons that you cannot take the internal evaluations here to be 'the final word'. Also, there are some caveats pertaining to the WritePixel test. Certain accelerators access the Amiga's bus in different ways, and thus may show slower (or possible faster) than another while being the opposite for other tests. This does not necessarily mean that boards with equivalent functions are 'defective', just that the bus access is different, (in some cases for compatibility reasons...and some of this is with good cause), and may show up as an APPARENT speed difference in the WritePixel test. In effect the WritePixel in all cases can be viewed as a speed of ROM routine AND bus access, and not the actual speed of the ROM image itself, as the WritePixel accesses the system bus in order to manipulate graphics memory. This is just a fact to keep in mind, and shows that, at least for the WritePixel test, what shows up may not be the full story. 4.) If you are using a 68020 or 68030 equipped accelerator, you probably know by now that in all cases you should have at least your instruction cache turned ON. This is especially true in a 16-bit RAM environment. In a 16-bit environment, with the instruction cache turned OFF, your system will take a SEVERE performance hit. The reason for this is such: The 68020 and 68030 instruction unit pre-fetches are 32-bit longwords. In a 16-bit memory situation, this is a 2 bus cycle process. In many cases, the second 16-bit word of the pre-fetch is thrown out. In a 32-bit environment, this is not a problem...but in a 16-bit environment, the result is fetching and then throwing out what is then fetched again, from the 16-bit RAM environment, thus adding another 2-bus cycle performance penalty. The 68000 does 16-bit pre-fetches, so it does not have a problem with this. The instruction cache on the 020 and 030 serves to 'buffer' this pre-fetch loss in the 16-bit environment. (I explained this poorly, but basically the idea is unless you are testing the performance degradation of such an operation...leave the Instruction cache ON unless you are in the 32-bit environment, and even then there isn't any real reason to turn it off, since the Instruction cache is read-only and does not suffer from the problems with DMA that the 030 data cache can have (Oh...the 040 and it's full bus snooping logic ought to fun, though...). One further thing pertaining to 030 caches...I do know of one board (there may be others) which does NOT use the Instruction cache while in ANY 16-bit environment...as per the reasons above it could show up as a major performance hit. Thus, it is best to know the accelerator being evaluated, and exactly what it and it's caches are doing (or capable of doing) in a given environment. 5.) The Dhrystone figures should be considered the most touchy. You can surely get a good representation on a medium-grade scale, but do not fine-judge anything with just one reading from this test (or any for that matter, but this one especially). The dhrystone test is particularly apt to give fluxuations due to cache inconsistancies on 020 and 030 machines. (or any cache-utilizing machine). The fluxuations are not astoundingly large, and because of that I was able to take a weighted average and use it for the internal comparisons between machines. (a weighted average was taken for all internal comparison machines.). The above tips of course (as said before) are only meant to help duplicate the conditions used for the figures obtained for the internal comparison machines. Now, even if you have the same type of machine as one of the comparison machines, you still may end up with slightly different figures. One of the major differences you may notice is an A2500/30 (or A2630) coming up a bit slower than the internal figures for an A2500/30, even with all the cache settings the same, is the use of faster RAM chips (the A2500/30 or A2630 accelerator is equipped with 100ns chips running with the processor at 3 wait states.) Now, you must remember, it will be almost IMPOSSIBLE for you to duplicate the EXACT figures for the internal machines, but given the exact same machine type, and settings/configuration you should come to within a reasonable range of the comparison figures. (The reason you cannot EXACTLY duplicate them most of the time is that no two machines are ever exactly alike). What you will get is basically an average mean value. This program is mainly useful for seeing if large differences are apparent between other types of accelerators. This program was basically meant to check CPU performance for other types of machines than the ones kept internally, however, you should feel free to change your processor settings, memory area/type where the program loads in, etc...should you happen to own one of the types of machines kept internally. This way you can see what the different settings, and such will do to your performance level as compared to optimum. Also, you can see just how well your machine does against a similar machine that may have more RAM or such, and CAN use BURST mode, provided your machine cannot, and so on and so forth. PROGRAMMING NOTES: I want to make a comment on the use of Disable() within this program. Disable() is a function designed primarily to allow a task to access data structures shared by interrupt code, without worry of having this code changed by an interrupt event during the access. My use of it here was because it was the only real way to insure that my program would have the best chance of being given total control of the procesessor. What I want to make clear is this: If you are just starting to program the Amiga, (or other multitasking systems for that matter), the use of Disable() or functions like it is to be a last resort, unless you are doing something very similar to what I have done here. Disable() is a very cruel thing to do to a multitasking system, and should be avoided if at all possible. There are some circumstances where it's use is necessary, to be sure, but it should be considered that my use of it here is NOT a standard method of usage for the call. [In fact, in most circumstances you should not be Disable()'ed for more than 250ms, as per the RKM recommendations.] In the context where I have used the call for this program, it won't cause problems provided the proper (mentioned earlier) environment exists. But to be sure, indiscriminate calls to Disable() and such are very poor programming practice. ACKNOWLEDGEMENTS: I wish to thank all of the folks who helped and supported me in this project. These individuals were all a part of the testing of this program, and influenced it's making a great deal: Bill Seymour: An all-around good-guy, and great help in this program's development. Michal Todorovic: For pointers on keeping my stack usage to a tolerable level :-). Michael Walters: Spotted a bug in my code early, and saved me many hours of debugging time... Dr. Scott Thayer: Sysop of Amiga Friends BBS, and spotter of program quirks :-) And of course, the beta testers who put up with my ceaseless requests for data: Mark Manes, Dan Dwyer, Steve Curry, Bill Hagan, Aryeh Goretsky, Tim Corcoran, Tom Thai, Stuart Logan, and Andrew Hobbs....Thanks!!! MISCELLANEOUS: Questions, comments, and suggestions about this program are quite welcome. I can be reached the following ways: Safe Harbor BBS: Amiga Hardware Special Interest Group Operator (SIGOP--SIG Area 7) (414)548-8140 I can always be reached here. AmiHolics BBS: (602)843-8486 Northwest Amiga Group (NAG): (503)656-7393 Amazing Connection BBS: (602)843-6574 Amiga Friends BBS: (714)870-4754 JDR Microsystems BBS: (408)559-0253 Miller's Amiga System BBS: (612)698-1485 I can also be found on Usenet: lkoop@crash!pnet01.cts.com (Internet) [pick your path :-)] and have been known to lurk around IntelecNet. If you wish, you can also contact me via the U.S. Mail service at LaMonte Koop 565 Park Meadows Dr. #302 Waite Park, MN 56387 About me...Well, I'm a near-fourth (A what?) year university student majoring in Electrical/Computer Engineering, Physics, and Mathematics. Why all three? Why not...they're all fairly related, and I find them hard to choose between. AIBB is the result of my fascination with both FAST computers, and the hardware that makes them...and everyone needs a hobby. I just happened to pick evaluation of accelerators for mine :-). If you have some interesting ideas for a project, let me know. I'm always looking for something to do :-). If it's not within my current capabilities, I will probably try to make it so. (Or yell AAARRRRRRGGGGHHHH really loud and mutter strange things :-) ). [Anybody ever thought of using the MMU as a memory defragmenting tool?... ...mmm, just a thought.]